平常打開 SIEM，大部分時間都在看告警。但有時候要處理的問題，是原本持續進來的資料，突然不見了。

我碰過 Agent 斷線，也碰過突然沒有繼續傳資料的情況。Sensor 則可能看起來還在線，但網路封包已經沒有進來。

遇到這些問題，我通常先從 SIEM 管理介面查看。先確認資料從什麼時候開始中斷，再看影響哪些來源，接著才往設備或現場查。

先找出資料從什麼時候停了

發現收集異常時，我會先找最後還有資料的時間，確認大概從哪一天、哪個時段開始中斷。

接著看影響範圍：只有單一 Agent 沒有資料，還是連 Sensor 收集的資料也停了？

如果一開始只說「SIEM 沒資料」，範圍太大，很難知道要從哪裡查。先把時間與來源弄清楚，後面查看狀態或詢問客戶時，才有比較明確的方向。

我會在管理介面查看系統提供的狀態與相關 Log，找看看有沒有異常訊息。看不出原因時，再遠端到設備上查看。

中斷時間也可以拿來對照環境變動。例如向客戶確認，附近時段是否有維護、重新接線或更動連接埠。這是整理這篇文章時可以延伸的排查方向，不代表只要時間接近，就已經找到原因。

Sensor 在線，封包卻可能沒進來

檢查時，我會把設備狀態與資料收集分開看。

管理介面顯示 Sensor 在線，我還是會確認它有沒有持續收到資料。因為我碰過設備在線，但網路封包已經中斷的情況。

對我來說，「在線」不能取代「有收到資料」的確認。原本應該進來的封包是否還在進來，才是這次要查的事情。

Agent 也可能出現不同狀況：有時候直接顯示斷線，有時候則是突然不再傳資料。至於原因，還是要繼續查看，不能只從沒有資料就認定哪個地方故障。

這篇先以 Sensor 的網路封包收集為主，分享我比較常用的檢查方式。

管理介面看不出來，就遠端到 Sensor 查

如果 SIEM 管理介面的資訊不夠，我會遠端到 Sensor，檢查機器的各項狀況，再確認是否有資料進入。

我多半使用設備本身提供的指令。這時主要想知道的是：機器運作有沒有異常，以及原本要收集的資料是否真的到達設備。

不同設備提供的指令不一樣，所以這裡先不列成指令教學。實際操作還是要依使用的產品查看。

遠端檢查也不一定能馬上找到原因。有些問題需要確認現場接線與連接埠狀況，能到現場的話，我就會再從實際收到的封包查看。

Mirror 埠是把流量複製給監控設備的位置

在說現場檢查之前，先簡單補充 Mirror 的用途。

交換器上的 Port Mirroring，常見的做法是把指定來源的流量複製一份，送到監控用的目的埠，讓 Sensor 或其他監控設備接收。

這裡有兩個位置要分清楚：一個是被觀察的來源，另一個是接收複製流量的目的埠。設定與接線要配合，Sensor 才能收到預期的資料。

這篇先知道這個概念就好。至於 Mirror 的設定方式，以及封包能提供哪些調查資訊，可以留到後面的文章再談。

到了現場，我會用筆電接 Mirror 埠

在現場時，我會把筆電接到原本送給 Sensor 的 Mirror 埠，再開啟 Wireshark，看看有沒有封包進來。

我使用 Wireshark 的目的很單純，就是確認有沒有資料。這一步沒有做到深入的協定分析，也沒有從封包中追查完整攻擊行為。

對當時的問題來說，先知道接到這個位置能不能收到封包，就能多一項資訊，幫助後續排查。

不過，看到封包，還不能直接說收集已經完全正常。

「有收到封包」、「收到的是預期的流量」，以及「Sensor 已經正常處理並送進 SIEM」，是不同的確認項目。我當時用筆電做的，主要是第一項。

如果要進一步確認，就需要再看封包的來源、目的位址與活動是否符合預期。這是可以繼續學習的方向，不是我當時已經完成的分析。

有時候，原因就在接線與連接埠

我確實碰過線路脫落，也碰過客戶更動連接埠的情況。

這些原因在 SIEM 畫面裡，不一定能直接看出來。平台可能只呈現資料停了，後面還是要查看設備，或確認現場狀況。

所以排查時，不能只把注意力放在 SIEM 裡面。資料來源到 Sensor 之間的接線與連接方式，也需要一起確認。

這裡提到的是不同次工作中遇過的情況，並不是一次完整案例。每次能取得的資訊、是否能遠端，以及能不能到現場，都會影響接下來怎麼查。

恢復收集，中間缺的資料卻不一定會回來

這裡要分網路封包與 Syslog 來看。

以我碰過的網路封包收集情況來說，中斷期間沒有收到的封包，通常就補不回來了。後來線路或收集恢復，看到的是重新開始進來的資料，不代表前面缺少的那一段也跟著補齊。

Syslog 則不一定。是否能補送，要確認來源端有沒有保留紀錄，以及使用的傳送工具是否支援緩存、重送或其他補送方式。來源端還找得到紀錄，也不代表它會自動重新送進 SIEM。

所以，恢復收集與補齊資料缺口，要分開確認。

這也是記下中斷時間的用途之一。除了協助找原因，之後如果需要調查那段時間，也能知道哪些資料可能不完整，不能把查不到紀錄直接當成沒有發生活動。

資料重新進來後，還要回頭看一下

排查完不能只停在設備重新在線。從前面這些情況來看，更需要確認的是原本中斷的資料是否已經重新出現，以及時間是否持續更新。

如果只恢復部分來源，也要把還沒恢復的部分分開記錄。至於中間缺少的資料，則依收集方式確認能不能補回。

這是這篇整理出的恢復確認方向。實際碰到問題時，還是要依現場狀況與產品提供的資訊處理。

我目前的排查方式，大致是先在 SIEM 找中斷時間與影響範圍，查看狀態和 Log；資訊不足，再遠端到 Sensor 檢查。能到現場時，就用筆電接原本的 Mirror 埠，透過 Wireshark 確認有沒有封包。

不是每次都需要走到現場，也不是每次都能立刻找到原因。但先把「在哪裡停了、停了多久、哪些資料受影響」弄清楚，至少知道接下來要查什麼。